home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / dos_win / winsock / maillist / 93-11.Z / 93-11 / text0104.txt < prev    next >
Encoding:
Text File  |  1993-11-30  |  6.9 KB  |  159 lines
  1. In article <laeeb.96.2CF37E70@rivm.nl> laeeb@rivm.nl (Erminio Ballerini) writes:
  2.  
  3. >In article <hmkriz.71.000945FA@vt.edu> hmkriz@vt.edu (Harry M. Kriz) writes:
  4.  
  5. >>For some time I was using PC/TCP version 2.2's winsock support to run PC 
  6. >>Eudora and Windows Trumpet. I found that within anywhere from 1 minute to an 
  7. >>hour of starting these programs, my mouse pointer would turn green. Later 
  8. >>during the day it would change to other colors while using these programs. I 
  9. >>figured it was something weird to do with the driver on my Diamond Stealth 
  10. >>VRAM card, which I run in 800x600x256 mode. Eventually I was going to look 
  11. >>into the problem.
  12.  
  13. >>Recently I switched this machine over to the Trumpet Winsock alpha#17 and 
  14. >>disabled PC/TCP. The mouse pointer no longer changes color when running these 
  15. >>programs. So, while it may still be a wierd driver problem with the card, it 
  16. >>seems it is related to PC/TCP, and not the winsock clients themselves.
  17.  
  18. >I also use PC/TCP 2.2, PC-Eudora (1.4b18) and WinTrumpet.
  19. >I have a Diamond Stealth 24 VLB which I run at 1024x768x265
  20. >(which looks nice on an Eizo F550i-W).
  21.  
  22. >And I have no problems with my mouse pointer at all.
  23.  
  24. Erminio:
  25.  
  26. I received a message from someone at FTP Software saying the problem had been 
  27. fixed in the IBMTR.EXE kernel. I, however, was using the generic ETHDRV.EXE 
  28. kernel. Also, another user of PC/TCP and the Diamond Stealth said he has the 
  29. same problem with the changing mouse pointer color. However, the problem does 
  30. not occur with his Diamond Speedstar.
  31.  
  32. Thus, it seems to be related to something in some kernels of PC/TCP working in 
  33. combination with some drivers for some resolutions of Diamond video cards. I'm 
  34. glad it isn't my job to try to fix these kinds of interactions.
  35.  
  36. --Harry
  37.  
  38.  
  39.  
  40. ----------------------------------------
  41. Harry M. Kriz           hmkriz@vt.edu
  42. University Libraries
  43. Virginia Polytechnic Institute
  44.  & State University
  45. Blacksburg, Virginia   USA    24061-0434
  46. From news@samba.oit.unc.edu  Fri Nov 26 16:17:40 1993
  47. Received: from samba.oit.unc.edu by SunSITE.unc.edu (SMI4.1/FvK 1.02)
  48.           id AA27632; Fri, 26 Nov 93 16:17:40 EST
  49. Return-Path: <news>
  50. Received: by samba.oit.unc.edu (5.65/TAS/11-16-88)
  51.     id AA27130; Fri, 26 Nov 1993 16:03:48 -0500
  52. Received: from GATEWAY by samba.oit.unc.edu with netnews
  53.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  54. To: winsock@calypso.oit.unc.edu
  55. Date: 24 Nov 1993 16:24:09 GMT
  56. From: eyork@bdmserver.mcl.bdm.com (Emmett York)
  57. Message-Id: <2d01r9$srj@burrito.abq.bdm.com>
  58. Organization: BDM
  59. Sender: ses@calypso.oit.unc.edu
  60. Subject: Packet and Programming
  61.  
  62. Ok  a few questions.  Lets say I have want to intercept the packet driver info in windows what do I do??
  63. How should I set up the receive call back function seeing one is protected(Win) and the packet is real mode?
  64. Any help is appreciated
  65. From news@samba.oit.unc.edu  Fri Nov 26 18:37:41 1993
  66. Received: from samba.oit.unc.edu by SunSITE.unc.edu (SMI4.1/FvK 1.02)
  67.           id AA05891; Fri, 26 Nov 93 18:37:41 EST
  68. Return-Path: <news>
  69. Received: by samba.oit.unc.edu (5.65/TAS/11-16-88)
  70.     id AA02343; Fri, 26 Nov 1993 18:32:10 -0500
  71. Received: from GATEWAY by samba.oit.unc.edu with netnews
  72.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  73. To: winsock@calypso.oit.unc.edu
  74. Date: Fri, 26 Nov 1993 18:30:20
  75. From: daf10@cwru.edu (David A. Ferrance)
  76. Message-Id: <daf10.20.00128203@cwru.edu>
  77. Organization: Case Western Reserve University
  78. Sender: ses@calypso.oit.unc.edu
  79. Subject: blocking
  80.  
  81. Can someone tell me about blocking and the WSAE_WOULD_BLOCK (not sure if that
  82. is it exactly-- close though).  I have no understanding of these concepts and 
  83. although so far it has not hurt me, I'm sure that it will eventually.  This is 
  84. until I can get home and get a book on the subject...
  85.  
  86.   thanks,
  87.      dave
  88. "If nature destined to be healthy, I would venture to assert that the state
  89. of reflection is a state contrary to nature, and that the man who meditates
  90. is a depraved animal." -Rousseau, A Discourse on Inequality
  91. From rcq@ftp.com  Sat Nov 27 10:37:44 1993
  92. Received: from ftp.com (babyoil.ftp.com) by SunSITE.unc.edu (SMI4.1/FvK 1.02)
  93.           id AA00393; Sat, 27 Nov 93 10:37:44 EST
  94. Received: from rcq.oysters.ftp.com by ftp.com via PCMAIL with DMSP
  95.     id AA18330; Sat, 27 Nov 93 00:31:14 -0500
  96. Date: Sat, 27 Nov 93 00:31:14 -0500
  97. Message-Id: <9311270531.AA18330@ftp.com>
  98. To: daf10@cwru.edu
  99. Subject: Re: blocking
  100. From: rcq@ftp.com  (Bob Quinn)
  101. Reply-To: rcq@ftp.com
  102. Cc: Multiple recipients of list <winsock@sunsite.unc.edu>
  103. Sender: rcq@ftp.com
  104. Repository: babyoil.ftp.com
  105. Originating-Client: oysters.ftp.com
  106.  
  107. Hi Dave!
  108.  
  109. >  Can someone tell me about blocking and the WSAE_WOULD_BLOCK (not sure if that
  110. >  is it exactly-- close though).  I have no understanding of these concepts and 
  111. >  although so far it has not hurt me, I'm sure that it will eventually.  This is 
  112. >  until I can get home and get a book on the subject...
  113.  
  114. The WSAEWOULDBLOCK (10035) error occurs when you call a function
  115. with a non-blocking socket and the operation cannot be completed
  116. by the WinSock DLL.  It basically says "if this were a blocking
  117. socket, I would have blocked to complete this operation."  So, for
  118. example, if you called recv() expecting to read data and there
  119. wasn't any to read or the WinSock.DLL was busy, the recv() call
  120. would fail with SOCKET_ERROR, and WSAGetLastError() would return
  121. the WSAEWOULDBLOCK error.
  122.  
  123. It is considered a "soft failure" (i.e. it is not catastrophic),
  124. and indicates that you should retry the operation.  You should retry
  125. after you yield to other Windows applications, so your application
  126. multitasks nicely.
  127.  
  128. Any application using non-blocking sockets should expect this
  129. error, and code for it.  This includes any application that calls
  130. ioctlsocket(FIONBIO) to explicitly make a socket non-blocking *AND*
  131. any that calls WSAAsyncSelect(), which automatically makes sockets
  132. non-blocking.  The WSAEWOULDBLOCK error can occur on the functions:
  133.     accept(), closesocket(), connect(),
  134.     recv(), recvfrom(),
  135.     send(), sendto(),
  136.     WSAAsyncGetHostByAddr(), WSAAsyncGetHostByName(),
  137.     WSAAsyncGetProtoByName(), WSAAsyncGetProtoByNumber(),
  138.     WSAAsyncGetServByName(), WSAAsyncGetServByPort()
  139.  
  140. WSAEWOULDBLOCK is the Windows Sockets version of the Berkeley
  141. Sockets EWOULDBLOCK error.  You won't find any books on Windows
  142. Sockets that will discuss this, but _UNIX Network Programming_
  143. by W.Richard Stevens (Prentice-Hall, ISBN 0-13-949876-1) is the
  144. definitive text on Berkeley Sockets programming.  For Berkeley
  145. Sockets application design you should look at _Internetworking
  146. with TCP/IP_ Volume III (BSD Socket Version) by Douglas E.
  147. Comer and David L. Stevens (Prentice-Hall, ISBN 0-13-474222-2).
  148.  
  149. There have also been a few magazine articles on programming
  150. with Windows Sockets.  Look at Martin Hall's _Guide to Windows
  151. Sockets_ for some pointers.  Its available as WSGUIDE.??? on
  152. sunsite.unc.edu in /pub/micro/pc-stuff/ms-windows/winsock.
  153.  
  154. Good Luck!
  155. --
  156.  Bob Quinn                                             rcq@ftp.com
  157.  FTP Software, Inc.                                No. Andover, MA
  158.  
  159.